The existence of a new VM type raises a question for the type checker. Obviously, class MyClass end will give us a type named MyClass but will there be a new built-in object type?

I imagine the use would mostly be for inverting type requirements to accept anything that wasn't an object (for e.g. serializing data) which might be niche but it's still worth considering in my opinion.

They can only be written at the topmost scope.

Why limit class bindings to top-level when they're not exported? I've wanted a lightweight class abstraction in a local function before.

Local, function, and type bindings can be defined in any scope, therefore it'd make sense to allow the same for classes.

Certainly an interesting RFC so far. A couple of questions:

Do we need access specifiers in Luau? Majority of the code written today do not need private fields, and since classes can capture up-values, do we truly need private fields? And since private fields are not going to be supported out of the box, it seems a little weird to include the public keyword at the moment. Perhaps for now, Luau can treat a field as public by default, and if an RFC for private passes, one could explicitly define public or private.

Why create a whole new type in the VM? Couldn't a syntax sugar be implemented in place for table objects with a metatable instead? It seems unnecessary to me.

Also, I believe inheritation will be important, as at the moment, you can already create classes with a lot of functionality and decent support for the type-checker (except for shared-self types, which should be coming eventually!), but when it comes to inheritation, things get rather difficult.

@deviaze would you be able to give an example of this?

I've wanted a lightweight class abstraction in a local function before.

@bradsharp

@deviaze would you be able to give an example of this?

I've wanted a lightweight class abstraction in a local function before.

Sure!

Here, the Dependency class is only relevant within its enclosing method (and would be a lot more readable as a class here).

https://github.com/deviaze/touchpaddy2/blob/025f0db3a7962f3297cae1817e618f12ffd7e951/src/platform.luau#L47

This doesn't seem to be stated in the RFC, but if public is the only privacy modifier right now and private is coming later, what will the default privacy be in the future when private does get added?

What does the C API look like for classes?

Just had a quick skim, but I noticed __index isn't allowed. Is there any provision for __index-like behaviour (maybe exclusively if it doesn't match any defined fields+methods)?

Looks pretty great, just some details that need to be ironed out in the RFC process!

I'm on board insofar as polishing OOP in Luau, but some of the specifics of this specific proposal leave me feeling a bit iffy.

The initial lack of support for private fields and methods is disappointing — understandable from the perspective of how the RFC describes the complications, but disappointing nonetheless. My concern with its omission pertains largely (if not entirely) to syntax and readability. Assuming users do not subscribe to prefixing bindings with _ to denote privacy, the lack of support for private members is likely to bring about a new category of visually messy code that the RFC otherwise does very well to amend.

There is "tension" between the syntax for fields and methods that we could honestly do better about. If functions are public by default, why do fields need to be declared with access modifiers? I'm also of the opinion that field should be a mandatory part of declaring fields: public field foo feels more in line with public function foo(), and, in combination with fields hypothetically no longer needing to be declared with an access modifier, field foo would feel more in line with function foo(). It seems an interesting decision that the keyword field is described as a mutually exclusive alternative to public/private instead of as something that works with public and private like function is already intended to.

I don't think public nor private by themselves are great indicators of something being a field. It might be more clear to C++ or C# users, but I feel it'd be quite unfamiliar to Luau users.

Even if a field keyword doesn't have prior art in other languages, it makes more sense to include it for readability reasons:

class Cat
    field name: string
    private field internal_id: number
    
    function meow(self, text: string)
    end
end

In my opinion, class fields without a private qualifier should be public by default since that's the default for fields in a Luau table.

I find the rationale on implementing visibility modifiers being in the vein of "may as well because we have to introduce some keyword so it doesn't look weird" to be very weak. This just seems like a very bad way to decide on language features.
Just a suggestion that was not mentioned but an unannotated field could just be t1: _ or if you are going to separate fields by whitespace in the grammar anyways, just allow it to be blank such as t2: . Or why not simply enforce they have to use types? We are talking about a feature being implemented post-type-system, I don't see why the language has to bend over backwards for people who don't want to use the strict type system.

Back on visibility modifiers, I think that if the goal is to avoid unwanted access, then there are better ways that already exist at the API or representation by putting that state behind handles, whether they are opaque references or simple indices into other structures. There does not need to be some keyword that adds a whole charade to how that data is being accessed that can ultimately be bypassed ostensibly.

Certainly an interesting RFC so far. A couple of questions:

Do we need access specifiers in Luau? Majority of the code written today do not need private fields, and since classes can capture up-values, do we truly need private fields?

Roblox has, in the past, released APIs written in Luau using conventions like _foo to denote private fields. People inevitably write code that directly accesses those private fields and now they are essentially part of the public API even though they were never meant to be.

Something more robust is needed. I'm working on a separate RFC to get into the details of this.

Why create a whole new type in the VM? Couldn't a syntax sugar be implemented in place for table objects with a metatable instead? It seems unnecessary to me.

We think there's a performance win to be had here: Class instances don't need the array part of a table, and we think that we can save some memory and improve cache locality by splitting the property hash table. The class object holds the set of keys in a particular class. The class instances just hold an array of values.

Also, I believe inheritation will be important, as at the moment, you can already create classes with a lot of functionality and decent support for the type-checker (except for shared-self types, which should be coming eventually!), but when it comes to inheritation, things get rather difficult.

Shared-self unfortunately did not work out. I spent a couple of months trying to implement it, and it turned out to be a lot more brittle than I had hoped. I cover this briefly in the RFC.

Roblox has, in the past, released APIs written in Luau using conventions like _foo to denote private fields. People inevitably write code that directly accesses those private fields and now they are essentially part of the public API even though they were never meant to be.

I still don't think this issue necessitates the implementation of access specifiers. Like I mentioned, an upvalue system could just be preferred instead.

class A
    function new()
         local privateField = 0
         local object = A()
         object.getter = function()
             return privateField
         end
         return object
    end
end

I believe a solution like this would be a better workaround. Of course, if private fields could be optimized somehow by the compiler, many people would be more okay with it.

That aside, I do believe the reasoning as to why public and private exists is weak. No keyword looks great, and if we're still going to have keywords for fields, then it should be made with a keyword like "field".

Shared-self unfortunately did not work out. I spent a couple of months trying to implement it, and it turned out to be a lot more brittle than I had hoped. I cover this briefly in the RFC.

That really sucks. Custom class modules perhaps would have benefitted from it. However, native classes in Luau sounds and works as a better option. I do look forward to potential optimizations, describing some of them would give this RFC a better foundation to work with.

Why limit class bindings to top-level when they're not exported? I've wanted a lightweight class abstraction in a local function before.

This restriction could be lifted someday. It's in place now just to keep things simple.

Just had a quick skim, but I noticed __index isn't allowed. Is there any provision for __index-like behaviour (maybe exclusively if it doesn't match any defined fields+methods)?

This is probably okay to add at a later date. It requires some extra complexity in the VM, but it should be fine.

The only reason I'm adamant about the parentheses is because unlike conventional OO languages, the fields of Luau classes are the constructor and have to be initialized. The standard syntax for fields doesn't reflect that since most languages like C# or JavaScript just treat their fields as zero-initialized/undefined until the constructor assigns a new value to them. Luau classes don't have the same mechanics, so the syntax is just a bad fit.

Mirroring a function call with the prior art of "default constructors" makes it very clear that fields are also the constructor and have to be initialized with something. It also neatly separates the instance fields from the class body, which opens up the possibility of adding other constructs like static fields to the class body easily:

class Person(name: string, id: number)
	local currentId = 0 -- static field
	
	function new(name: string)
		currentId += 1
		return Person(name, currentId)
	end
end

I'd like to see how static fields could be done in a cleaner way than this.

@alexmccord Also, just saying that making the constructor a normal function call solves your issue with missing keys since function arity isn't affected by nil:

local x = Name("Foo", "Bar", "Baz") -- valid, 3 args
local y = Name("John", nil, "Doe") -- valid, 3 args
local z = Name("Jane", "Doe") -- invalid, 2 args

I like the idea behind having fields "like function parameters" but do not like ordered parameters for construction. I have found these to be quite fragile when working with classes with a large number of fields, and always resulted in me creating a "from_table" static method.

It would be interesting syntax, possibly to extend to functions, where they can be defined using {} which is sugar for having a single table argument with the given keys. This mirrors how {} can call a function with the first argument as a table.

If that sounds like a useful extension then we could at first use () for classes, and later introduce {} for both classes and functions.

Mostly just food for thought.

function foo{ name: string, reps: number | nil }
    for i = 1, reps or 1 do
        print("Hi " .. name)
    end
end

class Cat{ name: string }
    function speak(self)
        print(self.name)
    end
end

foo{ name = "Alice", reps = 5 }
local bob = Cat{ name = "Bob" }

I feel like () this should be the case

class Cat( name: string )
function speak(self)
print(self.name)
end
end

function foo( name: string, reps: number | nil )
for i = 1, reps or 1 do
print("Hi " .. name)
end
end

And luau do a python with named variables

foo( name = "Alice", reps = 5 )
local bob = Cat( name = "Bob" )

Could this RFC be merged because its beeb 2 weeks with all of the major issues resolved? As I'd like to include class properties in #147

Yeah. I think this is just about ready to go.

Unless something surprising happens, I'll merge this RFC on Monday the 27th.

Thanks so much for the detailed feedback everyone!

function __tostring(self)
    return `Point \{ x = {self.x}, y = {self.y} \}`
end

What if I don't want to type function __tostring(self) for every function?

Like, I am looking at the above, and there's not even colors there. And if I'd copy paste this to someone, would they even know that this is for a class, if I didn't even include the portion there

I wish there was some keyword

function class:__tostring()
    return `Point \{ x = {self.x}, y = {self.y} \}`
end

So, I could just do this.

This doesn't mean the class is named class. class: is some kind of keyword that says that this just auto emits self.. idk

I cannot support merging if hoisting the class identifier is still planned. I don't care if everything else is perfect, variable hoisting is an unconditionally terrible feature that must be avoided at all costs.

Many dynamic languages like Python and Wren don't even bother with solving the mutually dependent class problem, and the ones that do like JavaScript solve it by invoking variable hoisting, where TDZ ensues. One of the best things about Lua(u) was that it did local variables right and only made identifiers visible in the order they lexically appeared, because any other visibility rule would be utterly confusing. Making classes an exception ruins this aspect of the language.

Again, you can still pull this off by using an explicit forward-declared variable. It's ugly, but it's the least evil option here.

local _B
class A
	function f() return _B {} end
end

class B
	function g() return A {} end
end
_B = B

An alternative to hoisting is some kind of syntax for mutually dependent declarations. You already need this with mutually dependent functions (whether local function, const function, or eventually export function), and now you need this with classes.

class Foo
  function f() return Bar.f() end
end
and Bar
  function f() return Foo.f() end
end

Python solves this problem essentially by hoisting everything.

def getX():
    return x

x = 22

print(getX())

How would this class look like https://paste.ivr.fi/irylyfegux.lua FloatVector with this or ArraySet?

Since it seems to use __index and __newindex.

If only proxies would solve it, then it would be a bit disappointing maybe.

Unless there's __cindex and __cnewindex specifically for classes idk